home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SGI Freeware 1999 August
/
SGI Freeware 1999 August.iso
/
dist
/
fw_xemacs.idb
/
usr
/
freeware
/
lib
/
xemacs-20.4
/
info
/
w3.info-3.z
/
w3.info-3
Encoding:
Amiga
Atari
Commodore
DOS
FM Towns/JPY
Macintosh
Macintosh JP
Macintosh to JP
NeXTSTEP
RISC OS/Acorn
Shift JIS
UTF-8
Wrap
GNU Info File
|
1998-05-21
|
47.2 KB
|
1,086 lines
This is Info file ../info/w3.info, produced by Makeinfo version 1.68
from the input file w3.texi.
INFO-DIR-SECTION World Wide Web
INFO-DIR-SECTION GNU Emacs Lisp
START-INFO-DIR-ENTRY
* Emacs/W3: (w3). Emacs/W3 World Wide Web browser.
END-INFO-DIR-ENTRY
This file documents the Emacs/W3 World Wide Web browser.
Copyright (C) 1993, 1994, 1995, 1996 William M. Perry Copyright (C)
1996, 1997 Free Software Foundation
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
File: w3.info, Node: MIME Support, Next: Security, Prev: Supported URLs, Up: Top
MIME Support
************
MIME is an emerging standard for multimedia mail. It offers a very
flexible typing mechanism. The type of a file or message is specified
in two parts, separated by a '/'. The first part is the general
category of the data (text, application, image, etc.). The second part
is the specific type of data (postscript, png, jpeg, etc.). So
`text/html' specifies an HTML document, whereas `image/x-xwindowdump'
specifies an image of an Xwindow taken with the `xwd' program.
This typing allows much more flexibility in naming files. HTTP/1.0
servers can now send back content-type headers in response to a request,
and not have the client second-guess it based on file extensions. HTML
files can now be named `something.png' (not a great idea, but possible).
* Menu:
* Adding MIME types based on file extensions:: How to map file
extensions onto MIME
types (e.g., `.png ->
image/png)'.
* Specifying Viewers:: How to specify external and internal viewers
for files that Emacs/W3 cannot handle natively.
File: w3.info, Node: Adding MIME types based on file extensions, Next: Specifying Viewers, Prev: MIME Support, Up: MIME Support
Adding MIME types based on file extensions
==========================================
For some protocols however, it is still necessary to guess the
content of a file based on the file extension. This type of guess-work
should only be needed when accessing files via FTP, local file access,
or old HTTP/0.9 servers.
Instead of specifying how to view things twice, once based on
content-type and once based on the file extension, it is easier to map
file extensions to MIME content-types. The variable that controls this
is `mm-mime-extensions'.
This variable is an assoc list of file extensions and the
corresponding MIME content-type. A sample entry looks like: `(".movie"
. "video/x-sgi-movie")' This makes all files that end in `.movie'
(`foo.movie' and `bar.movie') be interpreted as SGI animation files.
If a content-type is defined for the document, then this is
over-ridden. Regular expressions can NOT be used.
Both Mosaic and the NCSA HTTP daemon rely on a separate file for
mapping file extensions to MIME types. Instead of having the users of
Emacs/W3 duplicate this in lisp, this file can be parsed using the
`url-parse-mimetypes' function. This function is called each time w3
is loaded. It tries to locate mimetype files in several places. If the
environment variable `MIMETYPES' is nonempty, then this is assumed to
specify a UNIX-like path of mimetype files (this is a colon separated
string of pathnames). If the `MIMETYPES' environment variable is
empty, then Emacs/W3 looks for these files:
1. `~/.mime-types'
2. `/etc/mime-types'
3. `/usr/etc/mime-types'
4. `/usr/local/etc/mime-types'
5. `/usr/local/www/conf/mime-types'
Each line contains information for one HTTP type. These types
resemble MIME types. To add new ones, use subtypes beginning with x-,
such as application/x-myprogram. Lines beginning with # are comment
lines, and suitably ignored. Each line consists of:
type/subtype ext1 ext2 ... extN
type/subtype is the MIME-like type of the document. ext* is any
number of space-separated filename extensions which correspond to the
MIME type.
File: w3.info, Node: Specifying Viewers, Prev: Adding MIME types based on file extensions, Up: MIME Support
Specifying Viewers
==================
Not all files look as they should when parsed as an HTML document
(whitespace is stripped, paragraphs are reformatted, and lots of little
changes that make the document look unrecognizable). Files may be
passed to external programs or Emacs Lisp functions to be viewed.
Not all files can be viewed accurately from within an Emacs session
(PNG files for example, or audio files). For this reason, the user can
specify file "viewers" based on MIME content-types. This is done with
a standard mailcap file. *Note Mailcap Files::
As an alternative, the function `mm-add-mailcap-entry' can also be
used from an appropriate hook.*Note Hooks:: This functions takes three
arguments, the major type ("image"), the minor type ("png"), and an
assoc list of information about the viewer. Please see the URL
documentation for more specific information on what this assoc list
should look like.
File: w3.info, Node: Security, Next: Non-Unix Operating Systems, Prev: MIME Support, Up: Top
Security
********
There are an increasing number of ways to authenticate a user to a
web service. Emacs/W3 tries to support as many as possible. Emacs/W3
currently supports:
Basic Authentication
The weakest authentication available, not recommended if serious
security is necessary. This is simply a string that looks like
`user:password' that has been Base64 encoded, as defined in RFC
1421.
Digest Authentication
Jeffery L. Hostetler, John Franks, Philip Hallam-Baker, Ari
Luotonen, Eric W. Sink, and Lawrence C. Stewart have an internet
draft for a new authentication mechanism. For the complete
specification, please see draft-ietf-http-digest-aa-01.txt in the
nearest internet drafts archive(1).
SSL Encryption
SSL is the `Secure Sockets Layer' interface developed by Netscape
Communications (2). Emacs/W3 supports HTTP transfers over an SSL
encrypted channel, if the appropriate files have been
installed.*Note Installing SSL::
---------- Footnotes ----------
(1) One is ftp://ds.internic.net/internet-drafts
(2) http://www.netscape.com/
File: w3.info, Node: Non-Unix Operating Systems, Next: Speech Integration, Prev: Security, Up: Top
Non-Unix Operating Systems
**************************
* Menu:
* VMS:: The wonderful world of VAX|AXP-VMS!
* OS/2:: The next-best thing to Unix.
* MS-DOS:: The wonderful world of MS-DOG!
* Windows:: Windows NT, Chicago/Windows 95.
File: w3.info, Node: VMS, Next: OS/2, Prev: Non-Unix Operating Systems, Up: Non-Unix Operating Systems
VMS
===
:: WORK :: VMS Specific instriuctions
File: w3.info, Node: OS/2, Next: MS-DOS, Prev: VMS, Up: Non-Unix Operating Systems
OS/2
====
:: WORK :: OS/2 Specific instructions
File: w3.info, Node: MS-DOS, Next: Windows, Prev: OS/2, Up: Non-Unix Operating Systems
MS-DOS
======
:: WORK :: DOS Specific instructions
File: w3.info, Node: Windows, Prev: MS-DOS, Up: Non-Unix Operating Systems
Windows
=======
:: WORK :: 32bit Windows Specific instructions
File: w3.info, Node: Speech Integration, Next: Advanced Features, Prev: Non-Unix Operating Systems, Up: Top
Speech Integration
******************
:: WORK :: Emacspeak integration
File: w3.info, Node: Advanced Features, Next: More Help, Prev: Speech Integration, Up: Top
Advanced Features
*****************
* Menu:
* Disk Caching:: Improving performance by using a local disk cache
* Interfacing to Mail/News:: How to make VM understand hypertext links
* Debugging HTML:: How to make Emacs/W3 display warnings about invalid
HTML/HTML+ constructs.
* Hooks:: Various hooks to use throughout Emacs/W3
* Other Variables:: Miscellaneous variables that control the real
guts of Emacs/W3.
File: w3.info, Node: Disk Caching, Next: Interfacing to Mail/News, Prev: Advanced Features, Up: Advanced Features
Disk Caching
============
A cache stores the information on a page on the local machine. When
requesting a page that is in the cache, Emacs/W3 can retrieve the page
from the cache more quickly than retrieving the page again from its
location out on the network. With a well-populated cache, browsing the
web is dramatically faster.
The first time a page is requested, Emacs/W3 retrieves the page from
the network. When requesting a page that is in the cache, Emacs/W3
checks to see if the page has changed since it was last retrieved from
the remote machine. If it has not changed, the local copy is used,
saving the transmission of the file over the network.
To turn on disk caching, set the variable `url-automatic-caching' to
non-`nil', or choose the 'Caching' menu item (under `Options'). That
is all there is to it. Running the `clean-cache' shell script fist is
recommended, to allow for future cleaning of the cache. This shell
script will remove all files that have not been accessed since it was
last run. To keep the cache pared down, it is recommended that this
script be run from at or cron (see the manual pages for crontab(5) or
at(1) for more information)
With a large cache of documents on the local disk, it can be very
handy when traveling, or any other time the network connection is not
active (a laptop with a dial-on-demand PPP connection, etc). Emacs/W3
can rely solely on its cache, and avoid checking to see if the page has
changed on the remote server. In the case of a dial-on-demand PPP
connection, this will keep the phone line free as long as possible,
only bringing up the PPP connection when asking for a page that is not
located in the cache. This is very useful for demonstrations as well.
To turn this feature on, set the variable `url-standalone-mode' to
non-`nil', or choose the `Use Cache Only' menu item (under `Options')
File: w3.info, Node: Interfacing to Mail/News, Next: Debugging HTML, Prev: Disk Caching, Up: Advanced Features
Interfacing to Mail/News
========================
More and more people are including URLs in their signatures, and
within the body of mail messages. It can get quite tedious to type
these into the minibuffer to follow one.
With the latest versions of VM (the 5.9x series of betas) and Gnus
(5.x), URLs are automatically highlighted, and can be followed with the
mouse or the return key. How the URLs are viewed is determined by the
variable `browse-url-browser-function', and it should be set to the
symbol `browse-url-w3'.
To access URLs from within RMAIL, the following hook should do the
trick.
(add-hook 'rmail-mode-hook
(function
(lambda ()
(define-key rmail-mode-map [mouse-2] 'w3-maybe-follow-link-mouse)
(define-key rmail-mode-map "\r" 'w3-maybe-follow-link))))
File: w3.info, Node: Debugging HTML, Next: Hooks, Prev: Interfacing to Mail/News, Up: Advanced Features
Debugging HTML
==============
For those people that are adventurous, or are just as anal as I am
about people writing valid HTML, set the variable `w3-debug-html' to
`t' and see what happens.
If a Emacs/W3 thinks it has encountered invalid HTML, then a
debugging message is displayed.
:: WORK :: Need to list the different values w3-debug-html can have,
and
:: WORK :: what they do ::
File: w3.info, Node: Hooks, Next: Other Variables, Prev: Debugging HTML, Up: Advanced Features
Hooks
=====
These are the various hooks that can be used to customize some of
Emacs/W3's behavior. They are arranged in the order in which they would
happen when retrieving a document. These are all 'normal hooks' in
standard Emacs-terminology, meaning they are functions (or lists of
functions) that are called consecutively.
`w3-load-hook'
These hooks are run the first time a URL is fetched. All the
Emacs/W3 variables are initialized before this hook is run.
`w3-mode-hook'
These hooks are run after a buffer has been parsed and displayed,
but before any inlined images are downloaded and converted.
`w3-source-file-hook'
These hooks are run after displaying a document's source.
File: w3.info, Node: Other Variables, Prev: Hooks, Up: Advanced Features
Miscellaneous variables
=======================
There are lots of variables that control the real nitty-gritty of
Emacs/W3 that the beginning user probably shouldn't mess with. Here
they are.
`url-bad-port-list'
List of ports to warn the user about connecting to. Defaults to
just the mail and NNTP ports so a malicious HTML author cannot
spoof mail or news to other people.
`url-confirmation-func'
What function to use for asking yes or no functions. Possible
values are `'yes-or-no-p' or `'y-or-n-p', or any function that
takes a single argument (the prompt), and returns `t' only if a
positive answer is gotten. Defaults to `'yes-or-no-p'.
`w3-default-action'
A lisp symbol specifying what action to take for files with
extensions that are not in the `mm-mime-extensions' assoc list.
This is useful in case Emacs/W3 ever run across files with weird
extensions (.foo, .README, .READMEFIRST, etc.). In most
circumstances, this should not be required anymore.
Possible values: any lisp symbol. Should be a function that takes
no arguments. The return value does not matter, it is ignored.
Some examples are `'w3-prepare-buffer' or `'indented-text-mode'.
`w3-keep-old-buffers'
Whether to keep old buffers around when following links. To avoid
lots of buffers in one Emacs session, set this variable to `nil'.
I recommend setting it to `t', so that backtracking from one link
to another is faster.
`url-passwd-entry-func'
This is a symbol indicating which function to call to read in a
password. If this variable is `nil' at startup, it is initialized
depending on whether "EFS" or "ange-ftp" is being used. This
function should accept the prompt string as its first argument,
and the default value as its second argument.
`w3-reuse-buffers'
Determines what happens when `w3-fetch' is called on a document
that has already been loaded into another buffer. Possible values
are: `nil', `yes', and `no'. `nil' will ask the user if Emacs/W3
should reuse the buffer (this is the default value). A value of
`yes' means assume the user wants to always reuse the buffer. A
value of `no' means assume the user always wants to re-fetch the
document.
`w3-show-headers'
This is a list of HTTP/1.0 headers to show at the end of a buffer.
All the headers should be in lowercase. They are inserted at the
end of the buffer in a <UL> list. Alternatively, if this is
simply `t', then all the HTTP/1.0 headers are shown. The default
value is `nil'.
`w3-show-status, url-show-status'
Whether to show progress messages in the minibuffer.
`w3-show-status' controls if messages about the parsing are
displayed, and `url-show-status' controls if a running total of the
number of bytes transferred is displayed. These Can cause a large
performance hit if using a remote X display over a slow link, or a
terminal with a slow modem.
`mm-content-transfer-encodings'
An assoc list of CONTENT-TRANSFER-ENCODINGS or CONTENT-ENCODINGS
and the appropriate decoding algorithms for each. If the `cdr' of
a node is a list, then this specifies the decoder is an external
program, with the program as the first item in the list, and the
rest of the list specifying arguments to be passed on the command
line. If using an external decoder, it must accept its input from
`stdin' and send its output to `stdout'.
If the `cdr' of a node is a symbol whose function definition is
non-`nil', then that encoding can be handled internally. The
function is called with 2 arguments, buffer positions bounding the
region to be decoded. The function should completely replace that
region with the unencoded information.
Currently supported transfer encodings are: base64, x-gzip, 7bit,
8bit, binary, x-compress, x-hqx, and quoted-printable.
`url-uncompressor-alist'
An assoc list of file extensions and the appropriate uncompression
programs for each. This is used to build the Accept-encoding
header for HTTP/1.0 requests.
File: w3.info, Node: More Help, Next: Future Directions, Prev: Advanced Features, Up: Top
More Help
*********
For more help on Emacs/W3, please send me mail
(wmperry+w3@cs.indiana.edu). Several discussion lists have also been
created for Emacs/W3. To subscribe, send mail to
majordomo@indiana.edu, with the body of the message 'subscribe LISTNAME
<EMAIL ADDRES>'. All other mail should go to <listname>@indiana.edu.
* w3-announce - this list is for anyone interested in Emacs/W3, and
should in general only be used by me. The gnu.emacs.sources
newsgroup and a few other mailing lists are included on this.
Please only use this list for major package releases related to
Emacs/W3. (www-announce@w3.org is included on this list).
* w3-beta - this list is for beta testers of Emacs/W3. These brave
souls test out not-quite stable code.
* w3-dev - a list consisting of myself and a few other people who are
interested in the internals of Emacs/W3, and doing active
development work. Pretty dead right now, but I hope it will grow.
For more help on the World Wide Web in general, please refer to the
comp.infosystems.www.* newsgroups. There are also several discussion
lists concerning the Web. Send mail to <listname>-request@w3.org with
a subject line of 'subscribe <listname>'. All mail should go to
<listname>@w3.org. Administrative mail should go to www-admin@w3.org.
The lists are:
* www-talk - for general discussion of the World Wide Web, where its
going, new features, etc. All the major developers are subscribed
to this list.
* www-announce - for announcements concerning the World Wide Web.
Server changes, new servers, new software, etc.
As a last resort, mail me. I'll try to answer as quickly as I can.
File: w3.info, Node: Future Directions, Next: Reporting Bugs, Prev: More Help, Up: Top
Future Directions
*****************
Changes are constantly being made to the Emacs browser (hopefully all
for the better). This is a list of the things that are being worked on
right now.
:: WORK :: Revamp the todo list
File: w3.info, Node: Reporting Bugs, Next: Dealing with Firewalls, Prev: Future Directions, Up: Top
Reporting Bugs
**************
If any bugs are discovered in Emacs/W3, please report them to the
mailing list w3-beta@indiana.edu - this is where the brave souls who
beta test the latest versions of Emacs/W3 reside, and are generally
very responsive to bug reports.
Please make sure to use the bug submission feature of Emacs/W3, so
that all relevant information will be sent along with your bug report.
By default this is bound to the `<w>' key when in an Emacs/W3 buffer,
or you can use <M-x w3-submit-bug> from anywhere within Emacs.
For problems that are causing emacs to signal and error, please send
a backtrace. You can get a backtrace by `M-x setvariable RET
debug-on-error RET t RET', and then reproduce the error.
If the problem is visual, please capture a copy of the output and
mail it along with the bug report (preferably as a MIME attachment, but
anything will do). You can use the `xwd' program under X-windows for
this, or <Alt-PrintScreen> under Windows 95/NT. Sorry, but I don't
remember what the magic incarnation is for doing a screen dump under
NeXTstep or OS/2.
If the problem is actually causing Emacs to crash, then you will
need to also mail the maintainers of the various Emacs distributions
with the bug. Please use the gnu.emacs.bug newgroup for reporting bugs
with GNU Emacs 19, and comp.emacs.xemacs for reporting bugs with XEmacs
19 or XEmacs 20. I am actively involved with the beta testing of the
latest versions of both branches of Emacs, and if I can reproduce the
problem, I will do my best to see it gets fixed in the next release.
It is also important to always maintain as much context as possible
in your responses. I get so much email from my various Emacs-activities
and work, that I cannot remember everything. If you send a bug report,
and I send you a reply, and you reply with 'no that didn't work', then
odds are I will have no clue what didn't work, much less what that was
trying to fix in the first place. It will be much quicker and less
painful if I don't have to waste a round-trip email exchange saying
'what are you talking about'.
File: w3.info, Node: Dealing with Firewalls, Next: Proxy Gateways, Prev: Reporting Bugs, Up: Top
Dealing with Firewalls
**********************
By default, Emacs can support standard TCP/IP network connections on
almost all the platforms it runs on (Unix, VMS, Windows, etc).
However, there are several situations where it is not sufficient.
Firewalls
It is becoming more and more common to be behind a firewall or some
other system that restricts your outbound network activity,
especially if you are like me and away from the wonderful world of
academia. Emacs/W3 has several different methods to get around
firewalls (not to worry though - none of them should get you in
trouble with the local MIS department.)
Emacs cannot resolve hostnames.
This happens quite often on SunOS workstations and some ULTRIX
machines. Some C libraries do not include the hostname resolver
routines in their static libraries. If Emacs was linked
statically, and was not linked with the resolver libraries, it wil
not be able to get to any machines off the local network. This is
characterized by being able to reach someplace with a raw ip
number, but not its hostname (`http://129.79.254.191/' works, but
`http://www.cs.indiana.edu/' doesn't).
The best solution for this problem is to recompile Emacs, making
sure to either link dynamically (if available on your operating
system), or include the `-lresolv'.
If you do not have the disk space or the appropriate permissions to
recompile Emacs, another alternative is using the `nslookup'
program to do hostname resolution. To turn this on, set the
variable `url-gateway-broken-resolution' in your `~/.emacs' file.
This runs the program specified by `url-gateway-nslookup-program'
(by default "`nslookup'" to do hostname resolution. This program
should expect a single argument on the command line - the hostname
to resolve, and should produce output similar to the standard Unix
`nslookup' program:
Name: www.cs.indiana.ed
Address: 129.79.254.191
Using TERM (or TERM-like) Networking Software
TERM (1) for slip-like access to the internet.
NOTE: XEmacs and Emacs 19.22 or later have patches to enable native
TERM networking. To enable it, `#define TERM' in the appropriate
s/*.h file for the operating system, then change the `SYSTEM_LIBS'
definition to include the `termnet' library that comes with the
latest versions of TERM.
If you run into any problems with the native TERM networking
support in Emacs or XEmacs, please let wmperry+w3@cs.indiana.edu
know, as he is responsible for the original support.
Emacs/W3 has support for using the gateway mechanism for certain
domains, and directly connecting to others. The variable
`url-gateway-local-host-regexp' controls this behaviour. This is a
regular expression (2) that matches local hosts that do not require the
use of a gateway. If `nil', then all connections are made through the
gateway.
Emacs/W3 supports several methods of getting around gateways. The
variable `url-gateway-method' controls which of these methods is used.
This variable can have several values (use these as symbol names, not
strings), ie: `(setq url-gateway-method 'telnet)'. Possible values are:
"telnet"
Use this method if you must first telnet and log into a gateway
host, and then run telnet from that host to connect to outside
machines.
:: WORK :: document telnet gw variables
This section needs more information, specifically documenting the
following variables. For now, please do <C-h v> on the variable
for more information.
`url-gateway-telnet-host'
`url-gateway-telnet-parameters'
`url-gateway-telnet-password-prompt'
`url-gateway-telnet-puser-name'
`url-gateway-prompt-pattern'
"rlogin"
This method is identical to the `telnet' method, but uses `rlogin'
to log into the remote machine without having to send the username
and password over the wire every time.
:: WORK :: document rlogin gw variables
This section needs more information, specifically documenting the
following variables. For now, please do <C-h v> on the variable
for more information.
`url-gateway-rlogin-host'
`url-gateway-rlogin-parameters'
`url-gateway-rlogin-user-name'
`url-gateway-prompt-pattern'
"tcp"
Masanobu UMEDA (umerin@mse.kyutech.ac.jp) has written a very small
application that you can run in a subprocess to do the network
connections.
"SOCKS"
Use if the firewall has a SOCKS gateway running on it.
:: WORK :: document socks variables
This section needs more information, specifically documenting the
following variables. For now, please do <C-h v> on the variable
for more information.
`socks-host'
`socks-password'
`socks-username'
`socks-port'
`socks-timeout'
"native"
This means that Emacs/W3 should use the builtin networking code of
Emacs. This should be used only if there is no firewall, or the
Emacs source has already been hacked to get around the firewall.
Emacs/W3 should now be able to get outside the local network. If
none of this makes sense, its probably my fault. Please check with the
network administrators to see if they have a program that does most of
this already, since somebody somewhere at the company has probably been
through something similar to this before, and would be much more
helpful/knowledgeable about the local setup than I would be. But feel
free to mail me as a last resort.
---------- Footnotes ----------
(1) TERM is a user-level protocol for emulating IP over a serial
line. More information is available at
`ftp://sunsite.unc.edu/pub/Linux/apps/comm/term'
(2) Please see the full Emacs distribution for a description of
regular expressions
File: w3.info, Node: Proxy Gateways, Next: Installing SSL, Prev: Dealing with Firewalls, Up: Top
Proxy Gateways
**************
In late January 1993, Kevin Altis and Lou Montulli proposed and
implemented a new proxy service. This service requires the use of
environment variables to specify a gateway server/port # to send
protocol requests to. Each protocol (HTTP, WAIS, gopher, FTP, etc.)
can have a different gateway server. The environment variables are
`PROTOCOL'_proxy, where `PROTOCOL' is one of the supported network
protocols (gopher, file, HTTP, FTP, etc.)
For companies with internal intranets, it will usually be helpful to
define a list of hosts that should be contacted directly, not sent
through the proxy. The `NO_PROXY' environment variable controls what
hosts are able to be contacted directly. This should be a comma
separated list of hostnames, domain names, or a mixture of both.
Asterisks can be used as a wildcard. For example:
NO_PROXY=*.aventail.com,home.com,*.seanet.com
tells Emacs/W3 to contact all machines in the aventail.com and
seanet.com domains directly, as well as the machine named home.com.
For those adventurous souls who enjoy writing regular expressions,
all the proxy settings can be manipulated from Emacs-Lisp. The variable
`url-proxy-services' controls this. This is an assoc list, keyed on
the protocol type (HTTP, gopher, etc) in all lowercase. The `cdr' of
each entry should be the ADDRESS of the proxy server to contact,
followed by ":" and the port number to use. In the case of the special
"no_proxy" entry, it should be a regular expression that matches any
hostnames that should be contacted directly.
(setq url-proxy-services '(("http" . "proxy.aventail.com:80")
("no_proxy" . "^.*\\(aventail\\|seanet\\)\.com")))
File: w3.info, Node: Installing SSL, Next: Mailcap Files, Prev: Proxy Gateways, Up: Top
Installing SSL
**************
In order to use SSL in Emacs/W3, an implementation of SSL is
necessary. Emacs/W3 is configued to work out of the box with SSLeay
0.6.6 or later. For best results, you should apply a patch that makes
the SSLeay client much quieter about what it reports.
You can download SSLeay from `ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/'
The following variables control how the external program is invoked.
`ssl-program-name'
The name of the program to run, as a string.
(setq ssl-program-name "s_client")
`ssl-program-arguments'
This should be used if your SSL program needs command line
switches to specify any behaviour (certificate file locations,
etc). This is a list of strings and symbols.
The special symbols 'host and 'port may be used in the list of
arguments and will be replaced with the hostname and service/port
that will be connected to.
(setq ssl-program-arguments '("-host" host "-port" service "-verify" "4"
"-CApath /usr/local/ssl/certs"))
File: w3.info, Node: Mailcap Files, Next: Down with DoubleClick, Prev: Installing SSL, Up: Top
Mailcap Files
*************
NCSA Mosaic and almost all other WWW browsers rely on a separate file
for mapping MIME types to external viewing programs. This takes some of
the burden off of browser developers, so each browser does not have to
support all image formats, or postscript, etc. Instead of having the
users of Emacs/W3 duplicate this in lisp, this file can be parsed using
the `mm-parse-mailcaps' function. This function is called each time
Emacs/W3 is loaded. It tries to locate mimetype files in several
places. If the environment variable `MAILCAPS' is nonempty, then this
is assumed to specify a UNIX-like path of mimetype files (this is a
colon separated string of pathnames). If the `MAILCAPS' environment
variable is empty, then Emacs/W3 looks for these files:
1. `~/.mailcap'
2. `/etc/mailcap'
3. `/usr/etc/mailcap'
4. `/usr/local/etc/mailcap'
This format of this file is specified in RFC 1343, but a brief
synopsis follows (this is taken verbatim from sections of RFC 1343).
Each mailcap file consists of a set of entries that describe the
proper handling of one media type at the local site. For example, one
line might tell how to display a message in Group III fax format. A
mailcap file consists of a sequence of such individual entries,
separated by newlines (according to the operating system's newline
conventions). Blank lines and lines that start with the "#" character
(ASCII 35) are considered comments, and are ignored. Long entries may
be continued on multiple lines if each non-terminal line ends with a
backslash character ('\', ASCII 92), in which case the multiple lines
are to be treated as a single mailcap entry. Note that for such
"continued" lines, the backslash must be the last character on the line
to be continued.
Each mailcap entry consists of a number of fields, separated by
semi-colons. The first two fields are required, and must occur in the
specified order. The remaining fields are optional, and may appear in
any order.
The first field is the content-type, which indicates the type of data
this mailcap entry describes how to handle. It is to be matched against
the type/subtype specification in the "Content-Type" header field of an
Internet mail message. If the subtype is specified as "*", it is
intended to match all subtypes of the named content-type.
The second field, view-command, is a specification of how the
message or body part can be viewed at the local site. Although the
syntax of this field is fully specified, the semantics of program
execution are necessarily somewhat operating system dependent.
The optional fields, which may be given in any order, are as follows:
* The "compose" field may be used to specify a program that can be
used to compose a new body or body part in the given format. Its
intended use is to support mail composing agents that support the
composition of multiple types of mail using external composing
agents. As with the view- command, the semantics of program
execution are operating system dependent. The result of the
composing program may be data that is not yet suitable for mail
transport--that is, a Content-Transfer-Encoding may need to be
applied to the data.
* The "composetyped" field is similar to the "compose" field, but is
to be used when the composing program needs to specify the
Content-type header field to be applied to the composed data. The
"compose" field is simpler, and is preferred for use with existing
(non-mail-oriented) programs for composing data in a given format.
The "composetyped" field is necessary when the Content-type
information must include auxilliary parameters, and the
composition program must then know enough about mail formats to
produce output that includes the mail type information.
* The "edit" field may be used to specify a program that can be used
to edit a body or body part in the given format. In many cases,
it may be identical in content to the "compose" field, and shares
the operating-system dependent semantics for program execution.
* The "print" field may be used to specify a program that can be
used to print a message or body part in the given format. As with
the view-command, the semantics of program execution are operating
system dependent.
* The "test" field may be used to test some external condition (e.g.
the machine architecture, or the window system in use) to
determine whether or not the mailcap line applies. It specifies a
program to be run to test some condition. The semantics of
execution and of the value returned by the test program are
operating system dependent. If the test fails, a subsequent
mailcap entry should be sought. Multiple test fields are not
permitted--since a test can call a program, it can already be
arbitrarily complex.
* The "needsterminal" field indicates that the view-command must be
run on an interactive terminal. This is needed to inform
window-oriented user agents that an interactive terminal is
needed. (The decision is not left exclusively to the view-command
because in some circumstances it may not be possible for such
programs to tell whether or not they are on interactive
terminals.) The needsterminal command should be assumed to apply
to the compose and edit commands, too, if they exist. Note that
this is NOT a test--it is a requirement for the environment in
which the program will be executed, and should typically cause the
creation of a terminal window when not executed on either a real
terminal or a terminal window.
* The "copiousoutput" field indicates that the output from the
view-command will be an extended stream of output, and is to be
interpreted as advice to the UA (User Agent mail- reading program)
that the output should be either paged or made scrollable. Note
that it is probably a mistake if needsterminal and copiousoutput
are both specified.
* The "description" field simply provides a textual description,
optionally quoted, that describes the type of data, to be used
optionally by mail readers that wish to describe the data before
offering to display it.
* The "x11-bitmap" field names a file, in X11 bitmap (xbm) format,
which points to an appropriate icon to be used to visually denote
the presence of this kind of data.
* Any other fields beginning with "x-" may be included for local or
mailer-specific extensions of this format. Implementations should
simply ignore all such unrecognized fields to permit such
extensions, some of which might be standardized in a future
version of this document.
File: w3.info, Node: Down with DoubleClick, Next: General Index, Prev: Mailcap Files, Up: Top
Down with DoubleClick
*********************
:: WORK :: Document why doubleclick is evil
:: WORK :: Document how you can never see another ad from them again
File: w3.info, Node: General Index, Next: Key Index, Prev: Down with DoubleClick, Up: Top
General Index
*************
* Menu:
* 32-Bit Windows: Windows.
* Authentication, Basic: Security.
* Authentication, Digest: Security.
* AXP-VMS: VMS.
* Bad HTML: Debugging HTML.
* Basic Usage: Basic Usage.
* Broken SunOS libc: Dealing with Firewalls.
* browse-url-browser-function: Interfacing to Mail/News.
* Browser emulation: Emulation.
* Browsing with no network connection: Disk Caching.
* Buffer movement: Action.
* Bugs: Reporting Bugs.
* Cache cleaning: Disk Caching.
* Cache only mode: Disk Caching.
* Caching: Disk Caching.
* Cleaning the cache: Disk Caching.
* Clearing the cache: Disk Caching.
* Clueless in Seattle: Getting Started.
* Completion of URLs: Global History.
* Contacting the author: Reporting Bugs.
* Debugging: Debugging HTML.
* Default stylesheet: Startup Files.
* Digital VMS: VMS.
* Disk Cache: Disk Caching.
* DOS: MS-DOS.
* Emulation of other browsers: Emulation.
* Export Restrictions <1>: Installing SSL.
* Export Restrictions: Security.
* Exportability <1>: Installing SSL.
* Exportability: Security.
* Faulty hostname resolvers: Dealing with Firewalls.
* Firewalls: Dealing with Firewalls.
* Gag Puke Retch <1>: Installing SSL.
* Gag Puke Retch: Security.
* Getting Started: Getting Started.
* GNUS: Interfacing to Mail/News.
* History Lists: Session History.
* Hooks: Hooks.
* Hostname resolution: Dealing with Firewalls.
* HTTP Proxy: Proxy Gateways.
* HTTP/1.0 Authentication <1>: Installing SSL.
* HTTP/1.0 Authentication: Security.
* Interfacing to Mail/News: Interfacing to Mail/News.
* Invalid HTML: Debugging HTML.
* Limiting the size of the cache: Disk Caching.
* lpr-buffer: Miscellaneous.
* lpr-command: Miscellaneous.
* lpr-switches: Miscellaneous.
* Lynx emulation: Emulation.
* Microsloth <1>: Windows.
* Microsloth: MS-DOS.
* mime-types file: Adding MIME types based on file extensions.
* mm-add-mailcap-entry: Specifying Viewers.
* mm-content-transfer-encodings: Other Variables.
* mm-mime-extensions: Adding MIME types based on file extensions.
* mm-parse-mimetypes: Adding MIME types based on file extensions.
* MS-DOG: MS-DOS.
* MS-DOS: MS-DOS.
* Netless browsing: Disk Caching.
* Netscape emulation: Emulation.
* Newsgroups: More Help.
* No Proxy: Proxy Gateways.
* NO_PROXY: Proxy Gateways.
* Non-Unix Operating Systems: Non-Unix Operating Systems.
* OS/2: OS/2.
* Paranoia: Security.
* Persistent Cache: Disk Caching.
* Preferences: Preferences Panel.
* Proxies: Proxy Gateways.
* Proxies, environment variables: Proxy Gateways.
* Proxies, exclusion lists: Proxy Gateways.
* Proxies, setting from lisp: Proxy Gateways.
* Proxy Servers: Proxy Gateways.
* Relevant Newsgroups: More Help.
* Relying on cache: Disk Caching.
* Reporting Bugs: Reporting Bugs.
* RMAIL: Interfacing to Mail/News.
* scroll-down: Movement.
* Secure Sockets Layer <1>: Installing SSL.
* Secure Sockets Layer: Security.
* Security: Security.
* Security, Basic: Security.
* Security, Digest: Security.
* SSL <1>: Installing SSL.
* SSL: Security.
* ssl-program-arguments: Installing SSL.
* ssl-program-name: Installing SSL.
* Standalone mode: Disk Caching.
* Startup files: Startup Files.
* Support: More Help.
* TERM: Dealing with Firewalls.
* turn-on-lynx-emulation: Emulation.
* turn-on-netscape-emulation: Emulation.
* Turning on caching: Disk Caching.
* url-automatic-caching: Disk Caching.
* url-bad-port-list: Other Variables.
* url-confirmation-func: Other Variables.
* url-gateway-broken-resolution: Dealing with Firewalls.
* url-gateway-local-host-regexp: Dealing with Firewalls.
* url-gateway-method: Dealing with Firewalls.
* url-global-history-file: Global History.
* url-keep-history <1>: Global History.
* url-keep-history: Session History.
* url-passwd-entry-func: Other Variables.
* url-proxy-services: Proxy Gateways.
* url-show-status: Other Variables.
* url-standalone-mode: Disk Caching.
* url-uncompressor-alist: Other Variables.
* url-use-hypertext-dired: Action.
* url-view-url: Information.
* Usefulness of global history: Global History.
* Using Emacs/W3 with Gnus: Interfacing to Mail/News.
* Using Emacs/W3 with RMAIL: Interfacing to Mail/News.
* Using Emacs/W3 with VM: Interfacing to Mail/News.
* VAX-VMS: VMS.
* VM: Interfacing to Mail/News.
* VMS: VMS.
* w3: Getting Started.
* w3-backward-in-history <1>: Session History.
* w3-backward-in-history <2>: Action.
* w3-backward-in-history: Movement.
* w3-complete-link: Action.
* w3-debug-buffer: Debugging HTML.
* w3-debug-html: Debugging HTML.
* w3-default-action: Other Variables.
* w3-default-homepage: Getting Started.
* w3-document-information: Information.
* w3-document-information-this-url: Information.
* w3-end-of-document: Movement.
* w3-fetch <1>: Session History.
* w3-fetch: Action.
* w3-follow-inlined-image: Action.
* w3-follow-link: Action.
* w3-follow-mouse: Action.
* w3-forward-in-history <1>: Session History.
* w3-forward-in-history <2>: Action.
* w3-forward-in-history: Movement.
* w3-goto-last-buffer <1>: Action.
* w3-goto-last-buffer: Movement.
* w3-hotlist-add-document: Hotlist Handling.
* w3-hotlist-append: Hotlist Handling.
* w3-hotlist-apropos: Hotlist Handling.
* w3-hotlist-delete: Hotlist Handling.
* w3-hotlist-file: Hotlist Handling.
* w3-hotlist-refresh: Hotlist Handling.
* w3-hotlist-rename-entry: Hotlist Handling.
* w3-insert-formatted-url: Miscellaneous.
* w3-insert-this-url: Miscellaneous.
* w3-keep-history: Action.
* w3-keep-old-buffers: Other Variables.
* w3-latex-docstyle: Miscellaneous.
* w3-latex-packages: Miscellaneous.
* w3-latex-print-links: Miscellaneous.
* w3-latex-use-latex2e: Miscellaneous.
* w3-latex-use-maketitle: Miscellaneous.
* w3-leave-buffer <1>: Action.
* w3-leave-buffer: Movement.
* w3-load-hook: Hooks.
* w3-lynx-emulation-minor-mode: Emulation.
* w3-mail-current-document: Miscellaneous.
* w3-mail-document-under-point: Miscellaneous.
* w3-mode-hook: Emulation.
* w3-netscape-emulation-minor-mode: Emulation.
* w3-open-local: Action.
* w3-print-commnad: Miscellaneous.
* w3-print-this-url <1>: Miscellaneous.
* w3-print-this-url: Action.
* w3-print-url-under-point <1>: Miscellaneous.
* w3-print-url-under-point: Action.
* w3-quit <1>: Action.
* w3-quit: Movement.
* w3-reload-document: Action.
* w3-reuse-buffers: Other Variables.
* w3-save-as: Action.
* w3-save-this-url: Information.
* w3-save-url: Information.
* w3-scroll-up: Movement.
* w3-show-headers: Other Variables.
* w3-show-history: Session History.
* w3-show-history-list: Action.
* w3-show-hotlist: Hotlist Handling.
* w3-show-status: Other Variables.
* w3-source-document: Information.
* w3-source-document-at-point: Information.
* w3-start-of-document: Movement.
* w3-use-hotlist: Hotlist Handling.
* w3-use-links: Miscellaneous.
* w3-view-this-url: Information.
* w3-widget-backward: Movement.
* w3-widget-forward: Movement.
* Warp: OS/2.
* Windows '95: Windows.
* Windows (32-Bit): Windows.